The 3rd Generation Partnership Project (3GPP) has developed specifications for the delivery of Multimedia Broadcast Multicast Services (MBMS), which provides broadcast and multicast services over wireless networks. MBMS may be used for broadcasting of mobile television and radio services, as well as for file delivery, emergency alerts, and the like. Specifications are currently being developed for evolved MBMS (eMBMS), for deployment with networks based on 3GPP's specifications for Evolved Universal Terrestrial Radio Access (E-UTRA), also known as Long-Term Evolution (LTE).
Individual services provided by the MBMS system are known as MBMS Bearer Services. Each MBMS Bearer Service may be provided in a given service area using either multicast or broadcast modes. In MBMS the Multicast Control Channel (MCCH) is used for transmissions of control information required for reception of a Multicast Traffic Channel (MTCH). The MTCH is used for downlink transmission of MBMS services. There is one MCCH per MBSFN (Multicast-Broadcast Single Frequency Network).
The network uses a counting scheme to determine how many mobile devices (user equipment, or “UEs”, in 3GPP parlance) in any given service area are currently using or are interested in using a particular MBMS Bearer Service. The results of this counting process are used to determine how to best allocate resources for the service, such as whether a service session should be stopped in a given area, or whether one or more dedicated (i.e., unicast) radio channels might yield a more efficient use of system resources than a broadcast or multicast transmission.
A general description of and high level requirements for MBMS is given in the specification “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Multimedia Broadcast/Multicast Service (MBMS); Stage 1 (Release 10),” 3GPP TS 22.146, v 10.0.0, March 2011. A complementary specification, “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Multimedia Broadcast/Multicast Service (MBMS) user services; Stage 1 (Release 10),” 3GPP TS 22.246, v 10.0.0, March 2011, describes MBMS user services and user service requirements. Finally, a more detailed description of the MBMS system architecture and functionality is given in “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional description (Release 10),” 3GPP TS 23.246, v 10.1.0, June 2011.
FIG. 1 illustrates the overall architecture of the “Evolved Universal Terrestrial Radio Access Network” (E-UTRAN) portion of an LTE network 10. The network 10 includes the E-UTRAN 12 and an Evolved Packet Core 14 (or “core network”) portion of the network 10. The E-UTRAN 12 includes base stations (or “eNodeBs”) 16 which support wireless communication with one or more user equipment (UEs) 18. More specifically, the eNodeBs 16 provide the E-UTRA user plane (PDCP/RLC/MAC/PHY) and control plane (RRC) protocol terminations towards UEs 18. The eNodeBs 16 are interconnected with each other via the X2 interface. The eNodeBs 18 are also connected to the EPC 14 via the S1 interface. More specifically, the eNodeBs 18 are connected the MME (Mobility Management Entity) by means of the S1-MME interface and to the Serving Gateway (S-GW) by means of the S1-U interface. The S1 interface supports a many-to-many relation between MMEs/Serving Gateways and eNodeBs. Although a single reference numeral 20 is used to identify the MME and S-GW in FIG. 1, it is understood that these are separate logical entities, and possibly separate network nodes, with the MME communicating with the eNodeBs 18 via the S1-MME interface, and the S-GW communicating with the eNodeBs 118 via the S1-U interface.
The 3GPP TS 36.300 standard describes the functions performed by the MME and S-GW in great detail. FIG. 2 illustrates some of this functionality. In particular, FIG. 2 illustrates the functional split between the E-UTRAN 12 and the EPC 14. As shown in FIG. 2, the eNodeBs 18 hosts the following functions:                Functions for Radio Resource Management Radio Bearer Control, Radio Admission Control, Connection Mobility Control, Dynamic allocation of resources to UEs in both uplink and downlink (scheduling);        Selection of an MME at UE attachment when no routing to an MME can be determined from the information provided by the UE;        Routing of User Plane data towards the Serving Gateway;        Scheduling and transmission of paging messages (originated from the MME);        Scheduling and transmission of broadcast information (originated from the MME or O&M);        Measurement and measurement reporting configuration for mobility and scheduling; and        Scheduling and transmission of PWS (which includes ETWS and CMAS) messages (originated from the MME).        
Additionally, as further shown in FIG. 2, the MME 22 hosts the following functions:                NAS signalling;        NAS signalling security;        AS Security control;        Inter CN node signalling for mobility between 3GPP access networks;        Idle mode UE Reachability (including control and execution of paging retransmission);        Tracking Area list management (for UE in idle and active mode);        PDN GW and Serving GW selection;        MME selection for handovers with MME change;        SGSN selection for handovers to 2G or 3G 3GPP access networks;        Roaming;        Authentication;        Bearer management functions including dedicated bearer establishment;        Support for PWS (which includes ETWS and CMAS) message transmission; and        Optionally performing paging optimisation.        
FIG. 3 illustrates the logical architecture of eMBMS. The MBMS-specific components in FIG. 3 include the Multi-cell/multicast Coordination Entity (MCE) 24 and the MBMS Gateway (MBMS GW) 26. The MCE 24 is a logical entity that may be a standalone network node, or may be part of another network node (e.g., an eNodeB 16 or MME 22). The MCE 24 handles admission control and the allocation of the radio resources used by all eNodeBs 16 in the MBSFN area for multi-cell MBMS transmissions using MBSFN operation. The MCE 24 decides not to establish the radio bearer(s) of the new MBMS service(s) if the radio resources are not sufficient for the corresponding MBMS service(s) or may pre-empt radio resources from other radio bearer(s) of ongoing MBMS service(s) according to ARP. Besides allocation of the time/frequency radio resources, this also includes deciding the further details of the radio configuration, e.g., the modulation and coding scheme. The MCE 24 also performs the following functions:                Counting and acquisition of counting results for MBMS service(s);        Resumption of MBMS session(s) within MBSFN area(s) based on e.g. the ARP and/or the counting results for the corresponding MBMS service(s); and        Suspension of MBMS session(s) within MBSFN area(s) based e.g. the ARP and/or on the counting results for the corresponding MBMS service(s).The MCE 24 is involved in MBMS Session Control Signalling, but does not perform UE-MCE signalling. When the MCE 24 is part of another network element, an eNodeB 16 is served by a single MCE 24.        
The MBMS GW 26 is also a logical entity. The MBMS GW 26 may be a standalone network node, or may be part of another network node. The MBMS GW 26 26 is present between the Broadcast Multicast Service Center (BMSC) and eNodeBs 12 whose principal functions is the sending/broadcasting of MBMS packets to each eNodeB 16 transmitting the service. The MBMS GW 26 uses IP Multicast as the means of forwarding MBMS user data to the eNodeB. The MBMS GW 26 performs MBMS Session Control Signalling (e.g., session start/stop) towards the E-UTRAN via the MME 22.
FIG. 3 illustrates the M1, M2 and M3 interfaces. While the M1 is a user plane interface between the eNodeB 16 and MBMS GW 26, the M2 and M3 interfaces are control plane interfaces. The MCE 24 and MME 22 communicate via the M3 control plane interface. As described in 3GPP TS 36.300, “An Application Part is defined for this interface between MME and MCE. This application part allows for MBMS Session Control Signalling on E-RAB level (i.e. does not convey radio configuration data). The procedures comprise e.g. MBMS Session Start and Stop. SCTP is used as signalling transport i.e. Point-to-Point signalling is applied.”
The eNodeB 16 and MCE 24 communicate via the M2 interface. As described in 3GPP TS 36.300, “An Application Part is defined for this interface, which conveys at least radio configuration data for the multi-cell transmission mode eNodeBs and Session Control Signalling. SCTP is used as signalling transport i.e. Point-to-Point signalling is applied.”
In eMBMS, a counting procedure is used to determine the quantity of UEs 18 that are interested in receiving a service. Among other things, this allows the system operator to decide whether the service should be delivered using MBMS Single-Frequency Network (MBSFN), which involves the transmission of a stream from multiple, time-synchronized eNodeBs 16 serving a particular area.
The counting procedure is initiated by the network 10, with a request sent to each eNodeB 16 involved in a particular MBSFN area to perform a count. This request, called a “MBMS Service Counting Request,” is sent by the MCE 24 to each eNodeB 16. This triggers the eNodeBs 16 to send a Counting Request to their supported UEs 18, via the Multicast Control Channel (MCCH). The UEs 18, in turn, respond to their supporting eNodeB 16 with Radio Resource Control (RRC) Counting Response messages, which identify the MBMS services of interest to the UEs 18.
The MBMS Service Counting Request (or “base station counting request”) is sent by the MCE 24 to the eNodeB 16, to request that the eNodeB 16 report the number of connected mode UEs 18 that are receiving or are interested in receiving one or more identified MBMS services. The MBMS Service Counting Request is currently defined by 3GPP TS 36.443, v 10.2.0 (June 2011). As described by this specification, the MBMS Service Counting Request includes the following:                Message Type;        MCCH Update Time;        MBSFN Area ID; and        One or more TMGI identifiers (i.e., TMGIs).        
The MCCH (Multicast Control Channel) Update Time indicates a time at which the request should be made effective on the MCCH transmitted from the eNodeBs. A “TMGI” is a Temporary Mobile Group Identity. TMGIs are used to identify individual MBMS Service Bearers (i.e., individual MBMS services).
In response to the base station counting request, the eNodeB 16 sends back an MBMS Counting Results Report. This report is sent by the eNodeB 16 to the MCE 24, to report the number of connected mode UEs 18 that are receiving or are interested in receiving the one or more MBMS services indicated in the MBMS Service Counting Request message. The MBMS Counting Results Report is defined in 3GPP TS 36.443, v 10.2.0 as including the following:                Message Type;        MBSFN Area ID; and        MBMS Counting Result List (including, for each requested service, the TMGI identifying the service and a counting result).        
However under the reporting configuration in the 3GPP specifications discussed above, there are a number of issues with the MBMS Counting Results Report, as there are certain scenarios under which it is unclear at the MCE how to process the counting results.